I a h •. 


HCUWTV  ClAWFICATIOM  Of  Thi»  PAOK  ffc—  Mi  MmtanQ 


ItNT't  CATALOO  MUMBC* 


LANGUAGE  RESIGN  RISING  RECOMPILATION 


H.  COMTNOLLIMO  tmCI  NAMC  AND  ADOWIIS 

Experimental  Computer  Simulation  Laboratory,  N74 
Naval  Training  Equipment  Center 


Unclassified 


Approved  for  Public  Release;  Distribution  Is  unlimited 


Control  Structures 


FORTRAN 

Assembly  level  code 
Structured  programming 
Real-time  systems 


High-Level  Language 
Decompilers 
Compilers 
Data  types 


This  report  represents  the  results  of  a project  In  which  decompilation  tech- 
niques were  used  to  Identify  the  essential  characteristics  of  a high-level 
P'tvjrammlng  language  suitable  for  real-time  training  device  systems.  Tht 
project  consisted  of  three  phases.  First,  a decompiler  written  In  FORTRAN  was 
Implemented  to  map  assembly  language  for  a Xerox  SIGMA  7 computer  Into  a 
collection  of  tables  and  data  forming  the  basis  for  phase  3.  Second,  a struc- 
tures col  lection  of  33  modules  representing  an  operational  system  for  an  F-4 
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Item  20.  Continued 


trainer  was  decompiled.  Finally,  the  data  gathered  from  phase  2 was  analyzed 
to  Identify  language  features  appropriate  for  some  high-level,  application- 
oriented  programming  language. 


The  results  of  the  decompilation  showed  that  a hybrid  of  FORTRAN  Including 
bit-strings  and  locator  data  was  the  most  appropriate  high-level  language  for 
trainer  applications. 
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SUMMIT 

This  report  represents  the  results  of  s project  in  which  decoapilation 

▼ techniques  were  used  to  identify  the  essentisl  characteristics  of  a high- 

level  progressing  language  suitable  for  real-tiae  training  device  systeas. 

• The  project  consisted  of  three  phsses.  First,  a decoapiler,  written  in 

FORTRAN,  was  iapleaented  to  aap  ssseably  lsnguage  for  a Xerox  SIGMA- 7 
coaputer  into  a collection  of  tables  and  data  foraing  the  basis  for 
Phase  3.  Second,  a structured  collection  of  33  aodules  representing  sn 
operational  systea  for  an  F4  trainer  was  decoapiled.  Finally,  the  data 
gathered  froa  Phase  2 was  analyzed  to  identify  language  features  appro- 
priate for  soae  high-level,  application-oriented  progressing  language. 

The  results  of  the  decoapilstion  showed  that  in  addition  to  features 
typicslly  supported  in  conventional  scientific-oriented  progressing 
languages,  a language  suitable  for  trainer  systeas  siailar  to  the  F4 
should  include  bit-string  and  locator  data;  locator  data  is  data  that 
indirectly  references  other  dsta.  It  was  found  that  dynaaic  data 
structures  and  recursion  were  not  essential  whereas  control  aechanisas 
like  the  IF-THEN-ELSE , Zahn- loops,  DO -WHILE  and  REPEAT-UNTIL  were  very 
proainent  and  should  be  supported  in  such  a language. 
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PREFACE 

The  objective  of  this  project  is  to  apply  known  end  proven  decompiletion 
techniques  in  an  attempt  to  identify  patterns  and  structures  within 
asseably  language  source  code  that  Might  suggeat  or  correspond  to 
faailiar  constructs  found  in  aany  high-level  prograaaing  languages. 

This  effort  was  novel  in  the  sense  that  no  one,  to  our  knowledge,  has 
used  decoapilation  as  an  approach  to  language  deaign. 

Several  people  were  involved  at  varioua  atagea  of  this  project  and  we 
take  space  here  to  recognise  those  who  shared  in  the  effort.  Dr.  Terry 
Frederick,  Chairman  of  the  Coaputer  Science  Department  at  the  University 
of  Central  Florida  (foraerly  Florida  Technological  University),  was  co- 
principal investigator  on  this  project  and  acted  primarily  as  project 
adainistrator  and  consultant.  Dr.  Ron  Dutton,  also  a faculty  aeaber  in 
the  Coaputer  Science  Department,  UCF,  contributed  to  the  programming 
effort  and  provided  support  during  the  early  stages  of  development. 

Among  the  most  dedicated  contributors  to  this  effort  were  Robert  Larsen 
and  Sp*idharan  Menon  (graduate  assistants  at  UCF)  who  shared  most  of  the 
programming  and  debugging  effort  and  spent  seemingly  endless  hours  in 
the  coaputer  lab  running  the  decoaqtiler.  Finally,  Tsai  Bonar,  who  joined 
the  project  near  its  completion,  helped  with  debugging  and  progras: 
documentation. 
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SECTION  I 


INTRODUCTION 


CONTRACT  OBJECTIVES 


The  primary  objectives  of  this  contract  were  to  identify  and  foraulate 
the  features  of  a high-level  progressing  language  suitable  for  imple- 
menting aircraft  trainer  systeais.  The  specification  for  such  a language 
was  to  be  derived  froa  data  collected  on  research  systeas  currently 
operational  at  the  Naval  Training  Equipment  Center,  Orlando,  Florida. 


METHODOLOGY  AND  BACKGROUND 


Four  design  criteria  deteraine  to  a large  measure  the  features  comprising 
a high-level,  application-oriented  language.  First,  the  language  must 
contain  as  primitive  elements,  those  data  types  and  data  operations 
intrinsic  to  problems  in  the  application  area.  Secondly,  the  language 
should  be  "robust";  that  is,  it  should  allow  sufficient  variety  of 
constructs  to  aake  possible  the  precise  representation  of  computations 
and  control  structures  frequently  occurring  in  application  problens. 
Robustness  is  iaportant  because  it  gives  the  coapiler  writer  store  infor- 
mation about  the  precise  nature  of  a coaputation  making  possible  the 
generation  of  better  object  code;  this  is  particularly  iaportant  in  real- 
tiae  applications  like  those  encountered  in  aircraft  trainer  systeas.  A 
third  criterion  is  the  availability  of  features  that  add  to  the  self-docu 
aenting  properties  of  the  language;  features  of  this  kind  include 
constructs  that  induce  structure  in  the  control  and  data  flow.  This 
criteria  is  iaportant  because  it  increases  readability,  thereby,  sMking 
debugging  and  aaintenance  easier  and  more  effective.  Finally,  the 
language  should  be  high  in  its  expressive  power;  that  is,  it  should 
provide  constructs  permitting  complex  processes  to  be  expressed 
succinctly.  Expressive  power  in  a language  increases  prograaawr 
productivity  and  tends  to  diminish  his  propensity  for  error. 


The  primary  objective  of  this  contract  was  to  analyze  an  F4  trainer 
systea  written  in  the  asseably  language,  SYMBOL,  for  the  Xerox  SIGMA-7 
cosqmter.  This  analysis  was  to  be  carried  out  in  an  effort  to  gather 
data  sufficient  to  indicate  the  language  constructs  best  satisfying 
the  design  criteria  described  above.  Because  a high-level,  application' 
oriented  language  was  desired  and  because  the  F4  systea  was  written  in 
asseably  language,  decoapilation  was  a natural  choice  as  an  approach  to 
obtaining  the  desired  data. 

Decoapilation  aethods  have  been  studied^and  developed  by  House l1  and 
have  been  used  with  success  by  Friedaan  in  transporting  operating 


Housel,  B.C.  "A  Study  of  Decoapiling  Machine  Languages  into  High' 
Level  Machine  Independent  Languages",  Tech.  Report,  CSD-TR-1Q0, 
Purdue  University,  1973. 

Frieda»n,  F.L.  "Decoapilation  and  the  Transfer  of  Mini-Coaputer 
Operating  Systeas",  Ph.D.  Thesis,  Purdue  University,  1974. 
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systems.  Although  complete  decoapilation  of  assembly  language  programs  4 

it  normally  performed  with  some  predefined  high-level  syntax  as  a target, 
early  stages  of  the  decosq>ilation  process  produce  information  that  is 
essentially  language  independent  and  helpful  in  indicating  what  high-  * 

level  constructs  are  present  in  the  source  program.  In  the  next  section, 
we  describe  the  decompilation  process  more  fully,  Identify  the  type  of 
data  gathered  and  show  how  this  data  was  interpreted  to  suggest  those 
language  features  satisfying  our  design  criteria. 


I. 


6 


NAVTRAEQMIPCEN  77-C-0069-! 


* 


I 


SECTION  II 

DECOMPILATION  APPLIED  TO  LANGUAGE  DESIGN 
DECOMPILATION  AND  DATA  GATHERING 

The  first  phase  of  decompilation  performs  essentially  the  inverse  function 
of  code  generation  in  compilation;  that  is,  symbolic  machine  or  assembly 
language  is  OMpped  "up"  to  an  intermediate  low-level  language  that  is 
largely  swchine  independent.  During  this  process  statistics  can  be 
gathered  concerning  the  coaq>osition  of  the  original  source  code  with 
regard  to  special  operations,  data  types  and  addressing  modes.  This 
inforawtion  is  amst  significant  in  determining  the  simple  data  types 
that  must  be  supported  in  the  high-level  language.  Composite  data 
structures  like  arrays,  stacks,  queues,  linked  lists,  etc.,  are  much 
store  difficult,  if  not  impossible,  to  recognize  during  the  first  phase 
of  decosqtilation.  Detection  of  more  complex  data  types  is  possible  only 
by  considering  groups  of  instructions  in  combination  with  the  control- 
flow  structure  of  the  source  code. 

The  second  phase  of  decompilation  identifies  code  segments  called 
"blocks"  and  analyzes  the  control  flow  among  blocks.  The  effect  of 
this  phase  is  to  reduce  a program  module  to  a "flow  graph"  so  that  high- 
level  control  structures  (e.g.  FOR  and  DO  loops,  IF-THEN-ELSE)  can  be 
identified.  The  structure  of  a flowgraph  together  with  knowledge  regard- 
ing the  functional  properties  of  program  blocks  can  suggest  the  use  of 
complex  data  structures.  Flow  analysis  can  also  identify  regions  of 
the  program  absorbing  relatively  large  amounts  of  execution  time. 
Information  of  this  kind  is  extremely  important  in  suggesting  what 
optimization  techniques  should  be  employed  and  where  they  should  be 
applied. 

The  third  phase  of  decompilation  normally  performs  code  generation 
from  the  program's  flowgraph  representation  to  high-level  object  code. 
Since  the  high-level  source  language  was  an  unknown,  this  phase  of 
decompilation  was  not  impleamnted.  It  was  the  primary  objective  of 
this  contract  to  determine  the  most  isq>ortant  features  of  this  unknown 
language  based  on  the  data  gathered  by  the  first  two  phases  of  the 
decompilation  process.  We,  therefore,  present  in  the  following  para- 
graphs a detailed  description  of  each  of  these  decoispilation  phases, 
a summary  of  the  data  collected  in  each  phase  and  our  conclusions 
concerning  this  data. 

BLOCK  GENERATION  PHASE 

The  first  phase  of  decosq>ilation  was  designed  to  accomplish  the  fol- 
lowing objectives: 

1)  Identify  and  classify  "blocks"; 

2)  Classify  instructions  and  determine  frequency  distributions 
based  on  class; 

3)  Determine  a frequency  distribution  of  addressing  modes. 
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BLOCK  IDENTIFICATION  AND  CLASSIFICATION 


A "block"  is  defined  to  be  a sequence  of  instructions,  I ,1., — ,1  , 
with  Ij  representing  the  only  entry  point  to  the  sequence  and  if  for 
some  k,  1^  is  a transfer  instruction  (condition  or  unconditional),  then 
I.  is  a transfer  instruction  for  each  j>k.  Furthermore,  if  I.  is  an 
unconditional  transfer,  then  k=n.  Each  program  module  was  decomposed 
into  blocks  during  the  first  phase  of  decompilation.  An  instruction,  I 
defined  the  beginning  of  a new  block  whenever  I satisfied  one  of  the 
following  conditions: 


I represented  an  entry  point  to  the  module. 

I was  referenced  by  some  instruction  within  the  module. 

I was  a nontransfer  instruction  following  a transfer 
instruction. 

I was  the  first  instruction  following  a sequence  of 
instructions  from  which  I could  not  be  reached  except  by  a 
direct  transfer. 


Condition  4 is  really  subsumed  by  the  others  if  the  assumption  is  made 
that  no  "dead"  code  is  present  in  any  module.  To  keep  the  decompiler  as 
general  as  possible,  condition  4 was  included. 


Blocks  fall  into  three  functional  categories.  The  first  category  repre- 
sents all  blocks  that  evaluate  some  condition  prior  to  a logical  decision 
point  dependent  upon  that  condition.  Blocks  of  this  type  can  be  modelled 
by  the  following  high-level  statements. 


A sequence  of  nontransfer  statements 


IF  (EXPRESSION)  GOTO  LI 
GOTO  L2 


The  second  category  can  be  identifed  as  "loop  initialization."  Blocks 
in  this  category  contain  no  transfer  instructions  themselves  but  occur 
just  prior  to  a loop  entry  point. 


Loop  Initialization  Block 


— __ 
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The  third  category  contains  blocks  fonaing  the  alternatives  of  an  IF- 
THEN-ELSE  construct. 

IF (EXPRESSION)  GOTO  LI 


BLOCK  1 ("else"  alternative) 

I > 

GOTO  L2 
LI 


BLOCK  2 ("then"  alternative) 


L2 


£ 


The  functional  classification  of  blocks  becones  important  in  the  deter- 
nination  of  high-level  conditional  constructs  and  will  be  addressed  in 
the  next  subsection. 

In  addition  to  identifying  blocks,  it  was  necessary  to  asaign  a "type" 
to  each  block  that  would  be  useful  during  the  second  phase  of  decoupi- 
lation.  Block  type  could  be  any  value  in  the  range  1 to  7 depending  on 
the  particular  coaibination  of  the  following  three  properties  exhibited 
by  a given  block. 

1)  The  block  contained  an  entry  point  of  the  siodule. 

2)  The  block  contained  nodule  exit  or  return. 

3)  The  next  sequential  block  could  not  be  reached  except  by 
direct  transfer. 

Table  1 shows  the  correspondence  between  block  type  and  the  presence  of 
the  attributes  above.  An  "x"  entry  indicates  tbe  presence  of  an 
attribute. 

TABLE  1.  BLOCK  TYPE 


0 

1 

2 

3 

4 

5 

6 
7 


ATTRIBUTES 
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Block  type  was  used  not  only  for  flow-structure  analysis,  but  also  for 
determining  whether  or  not  the  high-level  objective  language  should 
support  a multiple-entry-point  feature  in  the  definition  of  subprogram: 
or  procedures.  The  results  of  the  decoaq>ilaton  revealed  the  figures 
displayed  in  Table  2.  This  data  was  based  on  a total  of  33  modules 
analyzed. 

TABLE  2.  ENTRY  POINT  DATA 


Number  of 

Entry  Points  Frequency  (No.  of  Modules). 

1 22 

2 3 

> 2 8 


Since  33  percent  of  the  modules  had  more  than  one  entry  point,  it  was 
apparent  the  multiple-entry  feature  should  be  included  in  the  high-level 
language. 

INSTRUCTION  CLASSIFICATION 

The  primary  source  of  information  used  to  identify  primitive  data  types 
for  the  high-level  languge  (HLL)  was  the  instruction  class  frequency 
distribution.  By  carefully  classifying  the  instructions  of  the  SIGMA-7, 
we  hoped  to  identify  the  use  of  one  or  more  of  the  following  data  types. 

1)  integer 

2)  single  precision  floating  point 

3)  double  precision  floating  point 

4)  string 

5)  logical  (true/false) 

6)  Boolean  (bit-string) 

7)  stacks. 

We  have  included  "stacks"  in  this  list  because  the  SIGMA-7  has  specific 
instructions  for  aumipulating  stacks.  Twenty-one  instruction  classes 
were  selected  in  an  attempt  to  identify  the  use  of  one  or  more  of  the 
data  types  above. 

1)  Bit  Operations/Non-Compare 

2)  Bit  Operation/Compare 

3)  Byte  Operations /Non-Compare 

4)  Byte  Operations/Compare 

5)  Half-Word  Operations/Non-Compare 

6)  Half-Word  Operationa/Compare 

7)  Full-Word  Operationa/Non-Compare 

I)  Full-Word  Operationa/Compare 
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9)  Double-Word  Opera tions/Non-Coapa re 

10)  Double-Word  Operations/Ccapare 

11)  Float-Sbort/Non-Coapare 

12)  Float-Sbort/Coapare 

13)  Float-Long/Non-Coapare 

14)  Float-Long/Coapare 

15)  Logical  (0R,E0R,AHD) 

16)  Stack  Operations 

17)  Branch-On-Condition 

18)  Branch-On-Count 

29)  Branch  (Subroutine  Linkage) 

20)  Miscellaneous 

21)  Exchange-Word. 

Soae  consents  are  in  order  concerning  the  interpretation  of  soae  of  these 
classes.  Class  1 consisted  priaarily  of  shift  instructions  and  instruc- 
tions that  set  hardware  conditions.  Class  3 consisted  of  byte-string 
operations.  Instructions  in  Class  5 were  interpreted  as  indexing  oper- 
ations for  loop  control  or  for  counting  purposes.  Classes  7 and  9 
represent  instructions  used  priaarily  for  true  integer  aritlusetic.  Classes 
11-16  are  self-explanatory.  Instructions  in  Class  17  were  assua^d  to  be 
used  for  conditional  logic  and  control  of  non-counting  loops.  Class  18 
denotes  instructions  used  primarily  to  control  counting  loops.  Class  20 
included  instructions  priauirily  pertaining  to  I/O  handling.  The  last 
class,  21,  consisted  of  the  "exchange-word"  instruction.  This  instruc- 
tion interchanges  or  "swaps”  two  aeaory  words.  Fonaing  a single  class 
froa  this  one  instruction  was  done  to  deteraine  if  a swap  function 
should  be  included  as  a syst®«  function  in  HLL.  Table  3 shows  the 
results  of  our  analysis  for  the  33,  F4-aodules.  Percentages  were  based 
on  a total  of  7,614  instructions. 


TABLE  3. 

INSTRUCTION-CLASS  FREQUENCY  DISTRIBUTION 

PERCENT* 

CLASS 

DESCRIPTION 

49.3 

7 

Ful 1-Word/Non-Coapare 

17.1 

17 

Branch-On-Condition 

16.1 

11 

Float-Short/Non-Coapare 

5.5 

19 

Subroutine  Linkage 

4.9 

8 

Ful 1 -Word/Coapare 

2.5 

1 

Bit-Operation/Non-Coaq>are 

2.1 

15 

Logical 

0.7 

20 

Misc.  (1/0) 

0.6 

2 

Bit  Operation/Cor^are 

0.5 

18 

Branch-On-Count 

0.4 

9 

Double-Word/Non- Coapa  re 

0.2 

21 

Exchange-Word 

0.0 

All  Other 

♦All  percentages  are  rounded  to  nearest  .1  percent. 
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The  rather  high  percentage  of  instructions  in  Class  7 can  be  explained 
by  noting  that  all  full-word  "load"  and  "store"  operations  belong  to 
this  class.  In  addition,  the  absence  of  representatives  from  Classer-  5 
and  6 suggest  that  indexing  and  counting  was  done  using  full-word 
operations.  Although  a more  definitive  classification  scheme  could  have 
disclosed  the  precise  composition  of  Class  7,  it  is  clear  that  full-word 
binary  integers  together  with  the  standard  arithmetic  operations  on 
integer  data  must  be  supported  in  HLL.  This  proposition  is  further 
supported  by  the  presence  of  classes  9,  18  and  8. 

Practically  all  computation  was  done  in  Class  11,  suggesting  HLL  should 
definitely  support  single-precison  real  arithmetic.  In  addition, 
manual  inspection  of  some  of  the  amdules  indicated  the  need  to  support 
all  trigonoswtric  functions  as  a standard  part  of  the  language.  A very 
aurprising  statistic  was  the  total  absence  of  classes  13  and  14. 

Logical  data  was  clearly  indicated  by  the  presence  of  Class  15  instruc- 
tions. The  surprisingly  high  frequency  of  Class  1 and  2 instructions 
suggest  some  facility  should  be  provided  in  HLL  for  defining  bit-string 
data  and  performing  bit-string  operations.  Manual  inspection  of  the 
code  indicated  that  most  bit  instructions  were  used  to  set  and  test 
"switches."  Since  approximately  half  the  modules  performed  bit  opera- 
tions, it  was  apparent  that  bit  data  should  be  an  essential  feature 
of  HLL. 

The  results  of  instruction-class  data  suggest  the  following  data 
facilities  should  be  supported  in  HLL. 

1)  Fixed-point  integer  data 

2)  Single-precision  floating-point  data 

3)  Bit  variables  and  bit  strings 

4)  Logical  data 

5)  Arithmetic  operations  for  Classes  1)  and  2) 

6)  An  Exchange-Word  primitive  function 

7)  Trigonometric  primitive  functions. 

ADDRESSING  MODES 

The  SIGMA-7  supports  a variety  of  addressing  capabilities.  Five  different 
addressing  modes  were  identified  for  the  purposes  of  our  analysis.  They 
are: 

1)  Direct  or  Absolute  Addressing 

2)  Indexing  via  registers 

3)  Indirect  addressing 

4)  A combination  of  2)  and  3) 

5)  Immediate 

In  addition  to  gathering  frequency  counts  for  these  five  addressing 
modes  within  each  instruction  class,  frequency  counts  were  also  main- 
tained for  "external"  references  in  each  instruction  class.  An  "external" 
reference  is  a reference  to  a data  item  or  instruction  defined  in  as 
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physically  distinct  nodule.  In  fact,  of  the  33  nodules  in  the  F4  soft- 
ware, 2 nodules  were  strictly  data  nodules;  that  is,  they  contained  no 
executable  instructions  and  served  to  resolve  nany  of  the  external 
references  isade  in  other  nodules. 

The  presence  of  indexing  usually  suggests  the  use  of  array  constructs 
of  one  or  nore  dinensions.  Indirect  addressing  is  typically  used  in 
addressing  paraneters  passed  to  a subroutine,  returning  fron  a subroutine 
call  and  in  accessing  and  swdifying  linked  data  structures  like  lists 
and  trees.  The  presence  of  external  references  to  data  inplies  the 
need  for  "global"  data  structures  as  provided  by  block  structured 
languages  like  ALGOL  on  Pl/1,  or  "cossson"  data  sinilar  to  that  supported 
by  FORTRAN . Table  4 summarizes  the  statistics  accumulated  for  addressing 
smdes. 

TABLE  4.  ADDRESSING  MODE  STATISTICS 

PERCENT  OF  INSTRUCTIONS 
(All  Modules) 


DIRECT 64.7% 

INDEXING 5.1% 

INDIRECT 1.3% 

INDIRECT  AND  INDEXING 0.4% 

IMMEDIATE 5.5% 

EXTERNAL 23.1% 


Practically  all  instances  of  indexing  in  the  F4  were  for  the  purpose  of 
array  addressing.  Indirect  addressing  was  used  in  three  contexts: 
First,  in  effecting  a return  fron  subroutine  call;  second,  in  accessing 
paraawters  passed  to  a subroutine;  and  finally,  indirect  addressing  was 
used  to  access  external  data  via  indirect  references  through  other 
external  variables  (sonetisMs  with  post-indexing).  The  first  two  uses 
of  indirect  addressing  represent  standard  linkage  mechanisms  for 
invoking  and  returning  fron  subprograms.  The  third  use  suggests  the 
addition  of  a new  data  type  to  the  HLL  which  we  shall  call  "locator" 
data.  A locator  variable  would  take  as  its  value  the  location  or 
address  of  some  other  data  structure.  To  support  the  locator  data 
type  would  require  including  a unary  address-operator  that  when  applied 
to  a data  structure  or  variable  returns  its  address.  Locator  variables 
would  allow  the  building  of  linked  data  structures  quite  easily  in  HLL. 

The  high  percentage  of  references  to  external  data  indicate  a clear 
need  for  the  COMMON  feature  found  in  FORTRAN.  Distinct  data  areas 
independent  of  any  particular  nodule  serving  as  a data  communication 
nedivm  between  two  or  nore  nodules  is  to  be  desired  over  the  parameter 
passing  mechanism.  This  is  particularly  true  if  the  number  of  data 
items  communicated  is  relatively  large.  Extensive  use  was  made  of  this 
swthod  of  data  communication  throughout  the  F4  system. 
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CONTROL  FLOW  ANALYSIS 

The  second  phase  of  decompilation  was  designed  to  construct  a flow 
graph  of  the  blocks  identified  in  the  first  phase.  In  addition,  statis- 
tics were  gathered  on  the  frequency  of  instruction  sequences.  Instruc- 
tion sequences  that  computed  the  value  of  some  expression  were  identified 
within  each  block  and  a count  of  their  frequency  of  occurrence  was 
suiintained  at  both  the  block  level  and  module  level.  It  was  hoped  that 
by  accumulating  instruction  sequence  data,  we  could  identify  simple 
functions  that  should  be  supported  in  HLL.  Unfortunately,  the  only 
sequences  that  occurred  with  significant  regularity  were  sequences 
containing  at  most  two  operators.  The  analysis  did  show  that  logical 
expressions  involving  AND,  OR  and  EXCLUSIVE-OR  represented  4.63  percent 
of  all  sequences  identified.  This  was  interpreted  as  sufficient  evidence 
for  support  of  these  operators  in  HLL. 

LOOP  ANALYSIS 

Perhaps  the  most  interesting  results  were  derived  from  the  identifi- 
cation and  classification  of  "loop"  constructs.  Our  purpose  was  to 
classify  all  loops  into  8 categories  according  to  the  number  and 
placement  of  loop  termination  points.  The  results  would  show  in 
addition  to  the  type  of  loop  constructs  needed  in  HLL,  the  "natural" 
frequency  of  occurrence  of  single-entry,  single-exit  loops  like  those 
proposed  by  Dijkstra  . 

I 

A "loop"  was  defined  as  a sequence  of  blocks,  Bj,  B^,...,  Bq,  satisfying: 

1)  B.  = B and  no  B.  other  than  B.(B  ) occurs  more  than  once. 

2)  Control  can  reac&  Bj  from  soaw1SK}9ule  entry  point  without 
passing  through  any1block  in  the  sequence. 

3)  Control  flow  can  pass  from  Bi  to  Bi+l*  lSi<n- 

The  "head  block"  of  a loop  is  always  its  entry  block,  B_.  The  "tail" 
of  a loop  is  always  the  block  B ,.  An  "interior  block"  is  any  block 
other  than  the  head  or  tail.  An  "exit"  block  is  any  block  from  which 
control  can  directly  pass  to  a block  not  in  the  loop.  Table  5 clas- 
sifies loops  according  to  whether:  1)  the  head  is  an  exit,  2)  an 
interior  block  is  an  exit,  3)  the  tail  is  an  exit  or  bosk  combination 
of  these  possibilities.  Note  that  type  0 loops  represent  infinite  loops. 


3.  Dshl,  O.J.,  Dijkstra,  E.W.  and  Hoare,  C.A.R., 
Academic  Press,  New  York,  1972. 


14 


NAVTRAEQU1PCEN  77-C-0069-1 


TABLE  5.  LOOP  CLASSIFICATION 


Attributes  Present 


Type  0 
1 
2 

3 

4 

5 

6 
7 


1 2 3 


X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

X 

Attributes : 

1 = Heed  Exit 

2 = Interior  Exit 

3 = Tsil  Exit 


The  results  of  the  loop  classification  were  very  interesting  particu- 
larly because  of  the  surprisingly  low  frequency  of  occurrence  of  the 
DO-WHILE  loops.  Class  4,  and  the  REPEAT-UNTIL  Loops,  Class  1.  Table 
6 gives  a complete  suasary  of  the  loop  analysis  data. 
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TABLE  6.  LOOP  CLASSIFICATION  DATA 


Nodule  No.  of  No.  of 

Hue  Blocks  Loops 


LOOP  DISTRIBUTION  BY  CLASS 


Totals 


Based  on  the  percentage  of  Branch-On-Count  instructions  in  Table  3, 
nuaiber  of  counting  loops  was  estiaated  to  be  16  percent  of  the  total 
masher  identified. 


The  loop  data  suggests  HLL  constructs  like  those  illustrated  below.  The 
"WHEN"  statement  causes  the  inner-nos t loop  containing  it  to  terminate 
with  control  being  passed  to  the  first  stateswnt  following  the  corres- 
ponding "LOOP"  stateaent.  Any  nuaber  of  WHEN  stateaents  would  be 
allowed  within  the  body  of  a loop.  A "counting'*  option  is  allowed  only 
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SECTION  III 
CONCLUSIONS 

We  summarize  our  findings  by  enumerating  those  features  characterizing 
a high-level  language  (HLL)  suitable  for  developing  applications  soft- 
ware for  aircraft  trainer  systems  similar  to  the  F4.  Many  of  the 
features  we  identify  are  common  to  many  conventional  programming 
languages.  These  include  integer  data,  floating  point  data  and  the 
usual  set  of  arithmetic  operators  that  apply  to  these  data  types. 

Logical  data  and  the  logical  operations  of  "AND",  "OR"  and  "NOT"  were 
also  found  to  be  necessary  features  in  HLL.  Static  array  structures 
and  COMMON  data  areas,  like  those  found  in  FORTRAN,  are  also  necessary 
elements  of  HLL.  HLL  should  also  support  facilities  for  permitting 
different  data  structures  to  share  the  same  storage  area;  a facility 
like  the  EQUIVALENCE  concept  in  FORTRAN  would  be  appropriate.  Because 
of  the  relatively  heavy  use  of  tabular  and  simple  data  that  were  constant 
or  "read  only"  data  structures,  some  facility  must  be  provided  in  HLL  for 
initializing  variables  and  arrays  at  compile  or  load  time.  Facilities 
for  defining  procedures  and  functions  with  multiple  entry  points  were 
also  found  to  be  desirable  ingredients  of  a language  designed  for  trainer 
systems.  Although  the  GOTO  construct  must  be  included  in  HLL,  its  use 
within  the  F4  software  was  very  seldom  found  to  be  the  result  of 
"irresponsible  style"  on  the  part  of  the  programmer. 

For  the  most  part,  the  features  we  have  listed  above  are  common  to  a 
number  of  popular  high-level  programming  languages.  We  complete  our 
summary  of  the  properties  ascribed  to  HLL  by  discussing  in  a little  more 
detail  those  features  that  were  very  prominent  in  the  F4  software,  but 
were  unusual  in  some  respect  and  therefore  of  special  interest  as  a 
result  of  this  research. 

DATA  STRUCTURES 

Add  LOCATOR  and  BIT(n)  as  new  data  types,  where  "n"  denotes  the  length  of 
a bit-string  variable.  LOCATOR  variables  take  on  values  that  represent  the 
location  or  address  of  some  other  data  item.  LOCATOR  variables  can  be 
typed,  dimensioned,  equivalenced,  placed  in  COMMON  or  passed  as  parameters 
just  as  any  other  variables.  BIT  variables  can  be  equivalenced  to  other 
variables. 

DATA  OPERATIONS 

While  both  LOCATOR  and  BIT  variables  should  be  allowed  in  mixed  mode 
expressions  (where  they  should  be  treated  as  INTEGER  data),  distinct 
operations  should  be  provided  for  each  type.  An  ADDR  built-in  or  system 
function  should  be  available  returning  the  location  of  its  argument. 
Operations  like  .AND.,  .NOT.,  .OR.  and  . EOR.  should  be  available  for  BIT 
variables.  A system  function  should  also  be  provided  for  exchanging  the 
values  of  two  variables. 


- ‘ • I- 
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CONTROL  STRUCTURES 

A loop-construct  like  the  one  illustrated  below  consists  of  a "DO" 
statement  having  an  optional  clause  with  three  distinct  foras  together 
with  a corresponding  "LOOP"  stateawnt  also  having  an  option  with  two 
alternative  foras.  Within  the  loop  body,  at  the  saae  nesting  level,  can 
be  any  nuaber  of  "WHEN"  stateaents.  Fora  1 of  the  DO  stateaent  is  for 
creating  a counting  loop  with  "V"  denoting  a control  variable  and  A-,  A., 
and  A.  denoting  arithaetic  expressions.  In  Forms  2 snd  3,  "WHILE"  takes 
a logical  expression  defining  s condition  for  entering  the  loop  body, 
whereas  "UNLESS"  takes  sn  expression  defining  a condition  for  terminating 
the  loop.  The  WHEN  stateswnt  defines  a condition  for  loop  teraination 
and  causes  control  to  pass  to  the  stateaent  iaswdiately  following  the 
LOOP  statesMint  if  the  condition  is  net. 


V = A , A [Ajl 

WHILE  (E)  J 
UNLESS  (E) 


WHEN  (E)  LEAVE 

LOOPfwHILE  (E)  “|  ; 

[UNLESS  (E)J 

In  addition  to  a new  loop  construct,  it  would  be  desirable  to  have  condi- 
tional constructs  like  IF-THEN  or  IF-THEN-ELSE  with  coapound  clauses.  The 
IF-THEN  stateaent  w^tld  introduce  a group  of  stateawnts  to  be  executed 
only  if  the  logical  expression  "E"  is  "true."  The  stateaent  group  would 
be  terainated  by  a aatching  "ENDIF"  or  "ELSE"  stateaent.  An  occurrence 
of  the  "ELSE"  would  signal  the  beginning  of  another  stateaent  group  to  be 
executed  only  if  "E"  is  "false."  The  ELSE  group  would  be  terainated  by 
the  ENDIF.  The  IF-THEN  and  IF-THEN-ELSE  constructs  could  be  nested  to 
any  depth. 


IF  (E)  THEN 


THEN-group 


ELSE-group 


ENDIF 
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1MPOT/OUTPUT 

While  some  evidence  existed  within  the  decompilation  data  suggesting 
facilities  should  be  provided  for  handling  I/O  interrupts,  it  is  no;  clear 
that  input/output  handling  at  this  level  should  be  supported  in  HLL;  this 
function  is  most  appropriately  performed  within  the  operating  system.  A 
compromise  would  be  to  allow  HLL  system  functions  that  could  check  for  the 
occurrence  of  various  kinds  of  interrupt  conditions,  returning  control 
only  if  the  condition  occurred  or  had  not  occurred. 

SUMMARY 

Real-time  programs  must  be  efficient  in  their  use  of  processor  time.  Pro- 
gramming at  the  machine  level  is  one  way  to  guarantee  a certain  level  of 
performance.  Programming  real-time  applications  in  a high-level  language 
has  obvious  advantages,  but  if  performance  of  the  object  code  is  of  para- 
mount importance,  the  choice  of  language  or  language  features  probably  has 
only  secondary  effects.  Using  good  programming  techniques  and  employing  a 
good  optimizing  compiler  will  most  probably  have  the  greatest  impact  on 
performance. 

While  this  project  has  sought  to  identify  those  features  essential  to  a 
high-level  language  suitable  and  "natural"  as  possible  for  implementing 
real-time  trainer  systems,  it  has  not  determined  the  degree  to  which 
language  design  effects  the  ultiauite  performance  of  such  systems.  The 
question  of  design  effectiveness  remains  open  and  represents  an  area  of 
further  research. 
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SECTION  IV 
RECOMMENDATIONS 

The  decompilation  approach  to  designing  a high-level  language  for  trainer 
applications  has  been  fruitful  and  has  produced  lose  unexpected  results. 
Nevertheless,  it  is  difficult  to  evalute  the  success  of  this  approach 
after  having  applied  it  to  only  one  system,  the  F4.  Further  studies  are 
needed  esgloying  this  technique  with  other  types  of  trainer  programs. 

In  addition,  a formal  specification  of  HLL  should  be  developed  along  with 
a compiler  using  a variety  of  optimization  algorithms.  Only  by  comparing 
the  performance  of  compiled,  unoptimized  and  optimized  HLL  code  with  the 
original  handwritten  machine  code  can  we  determine  the  most  significant 
factors  in  writing  and  maintaining  high-performance  trainer  application 
systems . 
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GLOSSARY 

addressing  mode:  the  process  by  which  a memory  operand  is  located  or 
fetched  for  a given  machine  instruction. 

bit-string:  a sequence  of  binary  digits  treated  as  a single  unit  or 
operand  in  some  operation. 

block:  a sequence  of  SMchine  instructions  whose  only  entry  point  is  the 
first  instruction  and  for  which  any  transfer  instructions  occur  at 
the  end  of  the  sequence. 

branch-on-condition:  a type  of  conditional  transfer  or  "jump"  instruction 
that  is  based  on  the  setting  of  hardware  condition  flags  preset  by 
the  execution  of  an  earlier  instruction. 

branch-on-count:  a type  of  conditional  transfer  or  "jump”  instruction 
based  on  the  value  of  some  counter  normally  held  in  a register. 

compiler:  a process  or  processor  designed  to  translate  procedures  written 
in  a source  language  to  equivalent  procedures  expressed  in  machine 
or  assembly  language. 

control  structure:  a programming  language  statement  or  group  of  state- 
ments designed  to  determine  the  flow  or  sequence  of  executable 
expressions . 

decompilation:  the  inverse  process  of  compilation;  that  is,  translating 
machine  or  assembly  language  procedures  into  a language  that  is  more 
programmer  oriented. 

entry  point:  the  location  to  which  control  is  passed  to  execute  or  acti- 
vate a program  module  or  block  within  a module. 

exit  block:  a block  within  a loop  from  which  control  can  leave  the  loop. 

external  reference:  a reference,  either  fetching  an  operand  or  transfer- 
ring control,  generated  in  one  module  but  resolved  to  or  satisfied 
by  another  module. 

flow  graph:  a collection  of  nodes  connected  by  directed  arcs.  Nodes 

correspond  to  program  blocks.  The  arcs  define  the  blocks  imsiediately 
accessible  from  a given  block. 

global  data:  data  that  is  accessible  in  one  sradule  but  not  defined  within 
that  module. 

head  block:  the  block  containing  the  entry  point  to  a loop. 

inswdiate  addressing:  the  method  of  fetching  an  instruction  operand  whose 
value  forms  part  of  the  instruction  being  executed. 
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indexing:  the  use  of  registers  in  adjusting  or  computing  an  addressable 
location  in  memory  that  varies  during  the  execution  of  a program 
segment . 

indirect  reference:  a reference  to  a data  item  or  instruction  operand 
obtained  by  fetching  the  value  of  another  memory  location  holding 
the  reference  address. 

interior  block:  any  block  within  a loop  other  than  the  head  or  tail  blocks. 

loop:  a sequence  of  instructions  or  blocks  that  can  be  repeatedly  executed 
as  a result  of  the  control  flow  structure  of  a module  or  program. 

module:  a group  of  program  statements  performing  a specific  function  with- 
in the  logical  organization  of  a program. 

parameter  passing:  the  mechanism  or  processing  convention  used  to  transmit 
a set  of  data  items  from  one  module  to  another  where  the  specific  s?t 
of  items  may  vary  from  one  call  of  that  module  to  another. 

source  code:  a program  written  in  a given  language  serving  as  the  input 
to  be  translated  by  a compiler  or  decompiler. 

subroutine  linkage:  the  instruction  sequence  executed  to  transfer  control 
from  one  module  to  another. 

syntax:  a finite  set  of  rules  describing  how  to  construct  programs 
expressed  in  a given  language. 

tail  block:  the  block  last  executed  before  the  head  block  within  a loop. 
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